Received: from yvax.byu.edu by maine.et.byu.edu; Fri, 4 Feb 1994 21:22:07 -0700
Return-Path: <mike@lorax.com>
Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-3 #4169)
id <01H8I358PEZK01ABV7@yvax.byu.edu>; Fri, 4 Feb 1994 21:24:11 MST
Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.3-3 #4169)
id <01H8I353WQ808Y5BW3@yvax.byu.edu>; Fri, 4 Feb 1994 21:24:05 MST
Received: from yvax2.byu.edu by alaska.et.byu.edu; Fri,
4 Feb 1994 21:23:15 -0700
Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.3-3 #4169)
id <01H8I33YLUKW01ABV7@yvax.byu.edu>; Fri, 4 Feb 1994 21:23:10 MST
Received: from netcomsv.netcom.com (uucp5.netcom.com)
by yvax.byu.edu (PMDF V4.3-3 #4169) id <01H8I33SO64G8Y5BVQ@yvax.byu.edu>; Fri,
4 Feb 1994 21:23:03 MST
Received: from lorax.com by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1)
id UAA09205; Fri, 4 Feb 1994 20:21:44 -0800
Received: by lorax.com (NX5.67d/NX3.0M) id AA16171; Fri, 4 Feb 94 18:40:41 -0800
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
Date: Fri, 04 Feb 1994 18:40:41 -0800
From: Mike Ferris <mike@lorax.com>
Subject: Re: Strings and other bad puns...
To: misckit@byu.edu
Reply-To: Mike Ferris <mike@lorax.com>
Message-Id: <9402050240.AA16171@lorax.com>
Content-Transfer-Encoding: 7BIT
Status: RO
Hi,
Some comments on String classes. I think that a radically different direction could be beneficial. I know from my experience with the MOString class that its hard to satisfy everyone with one object. I just get all the weird methods in there that people want, and people start commenting on how large and inefficient is seems to be getting.
I think that there might be a lot to be gained by taking an NXImage style approach to the whole thing.
I want a set of "representation" classes that provide back end data storage for string-type data. Then I want a good string class to wrap around them. I see representations for all sorts of strings like totally dynamic un-efficient reps, fixed size buffers, and static memory wrappers.
The string class would use one of these representations (and should be able to convert its data between reps.
To do this right would require an extremely carefully designed api between the representation classes and the string class.
There are probably other types of front-end objects that would be useful too.
But by doing something like this, users could have a choice when it comes to performance and memory issues and all that.
Having spouted all that, I must say that I cannot do this. Also, whenever there's thought being put into string classes it would be wise to consider Next's eventual entry into this area. When Next publicizes their string class, will we really want dozens of others to choose from. I suppose it depends on what Next provides, but before someone spends a huge amount of time writing new string classes, they should think about these issues.
